Executing In-network Queries Using SNEE

The SNEE query optimizer enables users to characterize data requests against wireless sensor networks (WSNs), using a declarative query language called SNEEql (SNEE for SensorNEtworkEngine, described in [GBG11], and publicly available at http://code.google.com/p/snee). Queries are compiled into imperative query execution plans, which are translated into executable nesC source code. In this paper, we illustrate the lifecycle of a SNEEql queryQ for in-network execution. This lifecycle encompasses the steps of preparatory metadata collection, followed by the compilation of Q into a query execution plan QEP , the dissemination of binary images implementing QEP throughout the WSN, and the generation of query results. To demonstrate our approach, we monitor light in a building using a simple 3-node WSN, depicted in Fig. 1, comprising of TelosB motes. In our WSN, node 1 is the gateway node (i.e., the node from which commands and query execution plans are disseminated to the WSN, and also where query results are collected), and nodes 2 and 3 monitor light levels for the upstairs and downstairs areas of the building respectively. The schema comprises three logical streams, building, upstairs and downstairs, of type (id:int, time:int, light:int). The building stream is the union of the upstairs and downstairs streams. The example queries that we use to illustrate our approach are shown in Fig. 2. Query (a) requests all the light readings in the building; (b) requests the average value of the light readings in the building; and (c) requests light readings when the light level upstairs is higher than downstairs (i.e., it may indicate that someone has forgotten to switch off a light). The QoS expectations are both an acquisition interval and delivery time of 10s (i.e., query results need to be delivered before the next tuple is acquired).